Systems employed in automation technology consist of a multiplicity of field devices such as, for example, sensors, controllers, filters, and drives. Should one of said field devices fail, a replacement device has to be used that operates with respect to the production process running on the system with the same operational characteristics as the original device. To insure that the new field device will display an appropriate operational behavior in the production process, said device must be suitably parameterized.
The replacement device is often not completely identical in design to the original device but of another type or from a different manufacturer. The parameters assigned to the original device cannot, therefore, simply be loaded into the replacement device. The old device parameters must therefore be transformed into new parameters for the replacement device by means of, for example, an engineering tool. That requires the old device parameters still to be accessible at the time the devices are changed over.
One possibility for acquiring the field device parameters is to use special software, tailored to the respective field device, for reading out the parameters. It may, though, no longer be possible to read out the parameters when a device is defective.
The device parameters can alternatively be stored on a central data server in order also to make the parameters accessible outside the device's own hardware. The centrally stored parameter assignment will not, though, necessarily tally with the parameter assignment stored on the field device. On-site changes are often made to a field device's settings by, for example, a service technician while it is operating. Said changes are difficult to detect locally and will then have to be reloaded back to the stored parameter assignment via other, additional communication paths.
What also correspond to the prior art are standardized device description languages that for a device class define which cross-vendor parameters describe a device. An example of this is the Electronic Device Description Language (EDDL). Said device description languages are, though, often supplemented by vendor-specific parameters for optimizations, for example, that cannot be transferred to another vendor when devices are changed over. Devices that implement the cross-vendor standard or an unsuitable version number cannot be registered.
A further approach, known from the prior art, to resolving the problem is to store the parameters on a replaceable storage medium, for example an MMC. When the device is changed over, only the storage medium will then have to be inserted into the new module to make the parameters available again. That requires the replacement device to be identical in design and likewise to have an apparatus for reading out the storage medium. That and all other previously cited methods known from the prior art generally necessitate storing the device parameters on a medium. The medium has to be read-accessed for transferring the device parameters to a replacement device, with its being necessary to use the same standard during reading and writing of the data. If the original device and field device are from different vendors, a cross-vendor standard will be necessary for this.